Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@alembic/versions/4b4b6b5d1c2a_add_verification_tokens_table.py`:
- Around line 32-43: Replace the redundant single-column index
ix_verification_tokens_id with a composite index on (user_id, expires_at) so
queries like delete_unexpired_tokens_for_user (in
app/crud/verification_token.py) can use an index; specifically, remove the
op.create_index call that creates ix_verification_tokens_id and instead add
op.create_index(op.f("ix_verification_tokens_user_id_expires_at"),
"verification_tokens", ["user_id", "expires_at"], unique=False). Make the same
replacement for the corresponding index in the later block (the second
occurrence around lines 47-50) so both upgrade and downgrade/other index
definitions reflect the composite index. Ensure ix_verification_tokens_token
(unique on token) remains unchanged.

In `@app/api/v1/endpoints/auth.py`:
- Around line 193-202: The current broad except around
auth_verification_service.resend_verification_email masks DB/token failures;
narrow the error handling so persistence errors propagate and only
email-producer failures are caught. Move the try/except so it surrounds just the
call to the email_producer (or have resend_verification_email raise a specific
EmailProducerError), catch that specific exception (e.g., EmailProducerError or
the producer's raised exception) and log via logger.warning("Failed to enqueue
verification resend for %s: %s", payload.email, exc); do not catch Exception
from within the overall resend_verification_email call so lookup/token mutation
errors surface as failures.

In `@app/crud/verification_token.py`:
- Around line 15-23: The create_token method (and the similar
revoke/current-token helper at lines 32-42) commits independently which can
cause a gap when called back-to-back from app/services/auth_verification.py;
change these helpers to support a no-commit mode (e.g. add an optional commit:
bool = True parameter or provide internal variants like _create_token_no_commit
and _revoke_current_tokens_no_commit) so they perform db.add/db.flush/db.refresh
without db.commit when commit is False, and then update the service layer to
call both helpers and perform a single db.commit() after both have succeeded;
reference the create_token function and the revoke_current_tokens helper when
implementing this change.

In `@app/services/auth_verification.py`:
- Around line 87-99: Don't delete unexpired tokens before emailing — instead
reuse an existing token if present or create a new one, then enqueue the email,
and only remove other tokens after send_email succeeds. Concretely: use the
repository method that returns existing tokens (e.g.,
get_unexpired_tokens_for_user) to pick/reuse a token; if none exists call
create_token to make one; build verification_link from that token; await
email_producer.send_email(...); only after send_email resolves successfully call
delete_unexpired_tokens_for_user (or a repository method that deletes other
tokens while preserving the just-sent token) to remove stale tokens.

In `@tests/test_auth/test_email_verification.py`:
- Around line 113-116: Replace the hard-coded UUID string in
test_verify_email_invalid_token_returns_custom_error with a programmatically
generated UUID (using uuid.uuid4()) so the request to
"/api/v1/auth/verify-email?token=..." still exercises the INVALID_TOKEN branch
without committing a literal that trips Gitleaks; update the test's client.get
call to interpolate uuid.uuid4().hex or str(uuid.uuid4()) for the token and
import uuid at the top of the test file if not already present.

---

Nitpick comments:
In `@app/crud/auth_verification_api.md`:
- Around line 82-83: Update the idempotency note for GET /verify-email to
clarify that tokens are single-use and are deleted upon successful verification
so reusing the same link will typically yield INVALID_TOKEN; only treat the
request as idempotent (returning 200) in the specific case where the user is
already verified and the token row still exists. Replace the existing second
bullet with wording that explicitly states: "Already verified users are handled
idempotently by GET /verify-email only when the verification token row still
exists; otherwise a reused link will result in INVALID_TOKEN." Ensure references
to "successful verification deletes the token", "GET /verify-email", and
"INVALID_TOKEN" remain in the doc so the behavior is clear.

In `@app/models/verification_token.py`:
- Around line 10-11: The model-level default_expiry() currently hardcodes a
24-hour TTL which duplicates and can contradict the TTL computed in
app/crud/verification_token.py; update default_expiry() to derive its timedelta
from settings.VERIFICATION_TOKEN_EXPIRE_HOURS (import settings) so the model
default and CRUD insertion use the same single source of truth for expires_at,
or remove the model default entirely and rely solely on the CRUD layer—adjust
the expires_at field and any references to default_expiry accordingly (see
default_expiry, expires_at and app/crud/verification_token.py).

In `@tests/test_auth/test_email_verification.py`:
- Around line 167-193: Add a regression test that simulates send_email raising
and asserts the old verification token is NOT invalidated: create a test (e.g.,
test_resend_verification_failure_does_not_invalidate_token) that uses the same
helpers (_create_unverified_user and _get_verification_token), capture
old_value, set email_producer_mock.send_email.side_effect = Exception("send
failure"), call POST /api/v1/auth/resend-verification, assert
email_producer_mock.send_email was awaited once, and then fetch the token via
_get_verification_token and assert its token equals the previously captured
old_value to ensure a failed send does not rotate the token.